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This paper deals with the development of a large systems program in a 
high-level language. The reasons for selecting a high-level language, the 
most extensively used features, the benefits derived, and the significant 
problems encountered are described. 

I. INTRODUCTION 

This paper highlights the important aspects of developing a large 
systems program in a high-level language. The Execution Preparation 
Facility (xpp) performs the linkage editor function on the Safeguard 
project. When xpf was originally designed, the decision was made to 
develop it in pl/1. The paper examines the most extensively used 
features of pl/1, describes the problems encountered during develop- 
ment, points out the lessons learned, and discusses the benefits derived 
from the use of a high-level language. An appendix provides xpf de- 
velopment productivity data and comparisons. 

II. FUNCTIONAL DESCRIPTION 

xpf is the last major step through which software must pass on its 
way to execution on the clc. Some functions performed by xpf can 
be compared to those of the operating-system linkage editor in that 
xpf prepares the output of the language processor for execution, sets 
up the overlay environment, and produces memory maps and cross- 
reference listings. 

The output of xpf, called a thread, is a collection of programs and 
data sets and their associated control tables bound to absolute ad- 
dresses. The thread also contains installation, debugging, and data 
reduction information. Inputs to xpf are user-supplied commands, 
execution time parameters, assembler or compiler output, a partitioned 
data set called the system file that describes the clc operating system, 
and, in an update mode, the results of previous xpf runs. 
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The major functions of xpf are construction of control vector tables 
(cvts) for interthread linkage, allocation of clc resources, primary 
memory and disc storage, binding of thread units, and construction of 
operating-system control tables (pcts). In addition, xpf produces a 
series of printed listings describing memory configuration, process 
structure, forward and back referencing among units, pct construction, 
and thread summary data. 

III. PHYSICAL DESCRIPTION 

xpf consists of 246 subroutines, 95 percent of which are written in 
PL/1. The internal structure is modular. Functions are performed by 
24 independent modules that overlay each other. The xpf load module 
consists of 130 overlay segments and requires 2.5 megabytes of disc 
storage. The access method used to retrieve object code, while not 
actually a part of xpf, is also included in the xpf load module. 

xpf operates in a 400-K region, of which 260 K is occupied by the 
overlaid load module. During execution, 12 internal files are used for 
work space and intermodule communication. Since the disc space 
needed for these files varies with the input, space allocation is con- 
trolled by catalogued procedure parameters. The actual execution of 
xpf is controlled by the execution time parameter field on the user's 
jcl execute card. Most modules execute at the option of the user and 
are controlled through this field. The mode of execution (regular, de- 
bug, or update) is also directed by execution time parameters. 

IV. DESIGN DECISIONS 

Since most systems software is written in assembly language, one 
question arises: Why was a high-level language used for this facility? 
Three major factors contributed to this decision. 

(i) Development time was short. It was felt that the anticipated 
ease of writing in a high-level language, coupled with extensive 
utilization of compiler-provided debugging capabilities, would 
help provide the desired results within the allocated time. 
This proved to be the case, and each of ten xpf releases was 
produced on schedule. 

(m) A high degree of flexibility was required, xpf, the operating 
systems, and the applications processes were to be developed 
concurrently. Since xpf is the software that links the operating 
systems and the applications processes, responsiveness to the 
design requirements of both groups was a necessity. A high- 
level language was judged to be best equipped to provide the 
required flexibility. This approach proved valid. In practice, 
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when a Safeguard design problem could have been solved by 
changing the clc operating system, the applications processes, 
or the xpf, xpf was usually chosen. 
(Hi) The execution of xpf was expected to be i/o limited. Therefore, 
potential compiler-generated cpu inefficiency was not a major 
consideration. 

Since xpf was to be developed and executed under os/360, the con- 
tenders for a high-level language were pl/1, Fortran, cobol, and 
algol. pl/1 was an easy choice. The bit-handling capabilities of the 
language were well known, and many members of the development 
group had pl/1 experience. 

V. HOW PL/1 WAS USED 

This section records those features of pl/1 used most extensively in 
the development of xpf. 

External variables were used to store relatively small amounts of 
data needed throughout xpf execution. Since the external variables 
were located primarily in the root segment of the load module, their 
use in intermodule communication aided in segmentation and structur- 
ing of the overlay tree. 

Static storage was used extensively to take advantage of what would 
have been dead space in the short legs of the overlay tree. The judicious 
use of static storage minimized the amount of memory required for 
execution. Static variables require special attention in an overlay en- 
vironment. Every time a segment is brought into memory, each static 
variable is reinitialized, but in subsequent calls to the segment that 
do not require overlay, the variables retain their current values. 

Three types of i/o were utilized. Stream-oriented i/o was used for 
printed listings and debugging output. Sequential-record-oriented i/o 
was used for intermediate files for communicating between, at most, 
two modules. The title option was used with these files to allow 
many modules to utilize the same disc area, thereby reducing overall 
resource requirements. Regional I update files were used to satisfy 
global communication requirements, e.g., paging of data and storage 
of object and bound units. 

Area variables were utilized by many modules. Each record entered 
into the update files consisted of a single area variable. Individual data 
entries were allocated within the area and entry addresses assigned. 
The use of areas avoided excessive i/o by allowing large amounts of 
data to be stored on a single record. The utilization of pl/1 area 
management greatly reduced the amount of user-supplied code neces- 
sary for record formatting and control mechanisms. 
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In the shorter legs of the overlay tree, area variables declared with 
the static attribute were employed, realizing the advantages described 

earlier. 

Based variables were used extensively, especially in the areas of i/o. 
Based structures were declared in the calling programs, and file 
managers returned pointers to the requested items. 

List processing was a major requirement in xpf design. Frequent 
sorts of these lists were required. The use of linked lists prevented 
excessive data movement during sorts, since only the pointers needed 
to be modified to change the order of the tables. 

The bit handling features of pl/1, an important aspect of the decision 
to use this language, were used extensively. Since the clc uses ascii 
character representation, characters had to be interpreted as bit strings. 

Label arrays were utilized in command processing. Since many 
commands contained common keywords and fields, processing was 
broken down to that level. Keywords and fields were interpreted and 
assigned number values that were used as indices into label arrays for 
keyword processing. 

The pl/1 preprocessor played an important role in xpf development. 
Preprocessor statements and procedures were placed on a file that 
was accessed via "% include" by all procedures. Four key functions 
were performed by the preprocessor : 

(i) Declarations of global data such as external variables and 
based variables used in i/o were stored on the file and brought 
into each procedure that utilized them. This assured identical 
variable declarations throughout xpf. 

(it) Declarations of utility and file manager entry points and their 
associated parameter attributes were also placed on the file. 
This helped assure the consistency of parameters passed to 
these subroutines. 
(in) Certain constants such as area sizes, array dimensions, and 
conversion constants were subject to frequent change while 
optimal values were being ascertained. Programs referencing 
these constants did so via preprocessor variables. When modifi- 
cations were necessary, the values of the preprocessor variables 
were changed on the file and the referencing programs were 
recompiled. 

(iv) Preprocessor procedures were provided for frequently used 
in-line code. 

VI. HOW ASSEMBLY LANGUAGE WAS USED 

While 5 percent of the subroutines in xpf are written in assembly 
language, these amount to less than 0.2 percent of the total number 
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of machine instructions. Assembly language subroutines fell into two 
categories : data conversion subroutines originally written in pl/1 and 
recoded in assembly language for reasons of storage economy or effici- 
ency, and subroutines written in assembly language to provide facilities 
not directly available in pl/1. 

An example of the first is a translate function that converts ascii 
to ebcdic, and vice versa. This function was not supported in pl/1 
Version 4. By recoding in assembly language, a 20-K-byte subroutine 
was reduced to 500 bytes and made much faster. 

An example of the second is a routine to access a partitioned data 
set of twenty or so members. Had this routine been written in pl/1, 
one dd card for each member of the data set would have been required. 

VII. MAJOR PROBLEMS ENCOUNTERED 

The most serious problem encountered during development was an 
obscure but critical bug in object code generated by pl/1 Version 4 
that became important when a new computer with a larger memory 
was installed, xpf would abend if loaded in the upper third of memory 
because of bad code generated for bit-string operations. This made it 
necessary to convert xpf to Version 5 of pl/1. Incompatibility between 
these versions required complete recompilation and some recoding. Six 
weeks of effort were required to complete the conversion. 

Another major problem was directly related to this conversion. 
Half-word storage, implemented in Version 5, caused structure align- 
ments to be altered. Since boundary alignments were not required on 
the development computer, some problems were not detected. It was 
later discovered that xpf would not work on certain models of the 
IBM System 360. The most expedient method of correcting the prob- 
lem was to declare the offending structures unaligned. Portability of 
xpf could probably have been ensured in advance by constantly being 
aware of the consequences of pl/1 defaults. 

The xpf execution problem causing the most impact was excessive 
i/o usage generated by the os overlay manager and not by pl/1. 
Dramatic reduction in load module accesses was accomplished by 
overlay restructuring. 

VIII. LESSONS LEARNED 

In addition to the initial decision to use pl/1, throughout the develop- 
ment of xpf many design and implementation decisions concerning 
the use of pl/1 were made. Some of these proved to be sound, and 
others had unfortunate results. This section deals with the results of 
these decisions. 

The extensive use of the pl/1 preprocessor proved to be an excellent 
control mechanism. The inclusion of macros, entry point declarations, 
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and global variable declarations via preprocessor procedures greatly 
facilitated intermodule communication. This standardization guar- 
anteed the integrity of interfaces. 

As originally expected, the liberal use of pl/1 debugging aids was an 
invaluable development tool. The large number of logic errors de- 
tected through on conditions such as subscriptrange and string- 
range underlines the value of their use. 

pl/1 provides no debugging aids for pointer variables, used ex- 
tensively in xpf, so it was frequently necessary to examine a dump to 
ascertain the exact nature of a problem. Since no error control phi- 
losophy within xpf had been established, dumps could not be produced 
at will. A global error control mechanism was instituted. By placing a 
single on error block in the main procedure and removing them from 
lower-level subroutines, the problem of inappropriate or inadequate 
response by these subroutines was eliminated. 

No global coding conventions were established at the beginning of 
the project. This resulted in various methods of implementation of the 
same basic requirements, some of which were more efficient than 
others. A subset of pl/1 should be extracted that is most efficient for the 
particular application. Programmers should be warned to avoid certain 
implementation methods and encouraged to use other more efficient 
ones. 

Since xpf was required to execute in a 400-K region (the maximum 
size for an express run), the use of small independent subroutines that 
could be overlaid was encouraged. In the longer legs of the overlay 
tree, this philosophy proved valid. However, in the shorter legs of the 
tree, this introduced unnecessary inefficiencies because of operating 
system overhead. The increased use of static storage in the shorter 
legs decreased the effect, but the use of fewer subroutines would have 
been more efficient. 

The use of assembly language subroutines, though dictated by 
reasons of efficiency and necessity, presents some disadvantages. Since 
parameter definition is compiler-dependent, assembly language sub- 
routines must be coded to meet the parameter passing standards and 
conventions of a specific compiler. In pl/1 these proved even more 
limiting since assembly language subroutines must be coded for a 
specific version of the compiler. When such subroutines are utilized, 
this dependency on a particular version of a compiler should be ex- 
plicitly documented. 

The assembly language complications are the most obvious of the 
compiler dependency problems. However, as noted previously, incom- 
patible compiler versions, the resulting recompilations required, and 
possible machine-dependent errors are also problems. Unless a private, 
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unchanging compiler is used, time must be reserved in the develop- 
ment schedule for this type of updating activity. 

IX. DISCUSSION 

Flexibility was one key factor in the decision to use a high-level 
language, and it proved to be one of the primary assets of the develop- 
ment technique. Since xpf was written in pl/1, it could be fine-tuned 
with less effort than if it were written in assembly language. Sections 
of code could be rewritten in a relatively short period of time. This 
made it feasible to experiment with implementation methods until 
optimal code was produced. 

One benefit of development in pl/1 that was not considered in the 
original decision was the ease with which transfer of responsibility is 
accomplished. Partial turnover of personnel occurred throughout the 
project. The transfer of code responsibility to new personnel was ac- 
complished very smoothly with no apparent decrease in productivity. 
Since pl/1 can be largely self-documenting through the use of mean- 
ingful variable names and standard operation symbols, it is easy to 
read and understand. This ease of understanding was the primary 
reason for the smooth personnel transitions. 

Perhaps the most important advantage of developing a system in 
a high-level language is that the compiler provides area management, 
storage allocation, error control, data access, and i/o interfaces. The 
programmers can devote their time to acquiring expertise in the unique 
requirements of the system. 

APPENDIX 

Over a period of two years (by Release 8), xpf grew to approximately 
32,000 pl/1 plus assembly-language statements. Almost all the 

Table I — Comparative productivity, Release 9 





snx Assembler 


clc Simulator 


XPP 


Total no. of .subroutines 


72 


90 


231 


Total no. of source statements 


69,788 


63,737 


34,344 


No. of subroutines added or 








changed 


40 


30 


84 


Percent of total subroutines 


55.5 


37.7 


36.3 


No. of source statements added 








or changed 


3,286 


2,336 


7,342 


Percent of total source 








statements 


4.7 


3.6 


21.3 


Alan-months programmer, 








management, librarian 


23.5 


10.5 


37.0 


Statements per man-month 


140 


222 


198 


Man-months, programmers only 


18.4 


9.0 


30.0 


.Statements per man-month 


177 


259 


244 
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changes for each release were planned increases in capability, although 
some, of course, were fixes for bugs. The total effort to produce the 
first eight releases, debugged and tested, was 222 man-months. The 
average productivity over this time is therefore about 140 statements 
per man-month. 

Table I compares Release 9 of xpf to the corresponding releases of 
the snx assembler and the clc simulator, both written in assembly 
language. The simulator was a considerably easier task than xpf for 
this release because the simulator was only receiving maintenance, 
while 21.3 percent of xpf was rewritten to add major new capabilities. 
Nevertheless, the total number of machine instructions produced (per 
man-month) by the xpf group was greater because they were coding 
in PL/1, whereas the assembler and simulator groups were coding in 
assembly language. 
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